• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    A disclosed exemplary method for use in a device configured to communicate using digital certificates comprising, in response to a request, receiving a digital certificate for use in secure communication between the device and another device; using a logic circuit, evaluating the digital certificate to determine a validity of the digital certificate; if the digital certificate is valid, allowing the device to use the digital certificate; and if the digital certificate is invalid, preventing the device from using the digital certificate.
    公开号:BE1027391B1
    申请号:E20205477
    申请日:2020-06-26
    公开日:2021-11-08
    发明作者:Jared Coy Roundy；Andrew J Pekarske；Christian S Rothwell
    申请人:Zebra Tech；
    IPC主号:
    专利说明:

    METHODS AND DEVICE FOR RENEWING DIGITAL CERTIFICATES
    FIELD OF THE DISCLOSURE This disclosure relates generally to security of electronic communications and, more particularly, methods and apparatus for renewing digital certificates.
    BACKGROUND Devices communicating externally typically include one or more forms of security for, for example, encrypting data, decrypting data, and/or authenticating data sources. One type of security technique, namely asymmetric encryption, involves public and private key pairs. Broadly speaking, each device securely stores a private key that is mathematically associated with a corresponding public key. The public key, which is shared with external devices, is used to encrypt information. The private key, which is not shared with external devices, is used to decrypt data that was encrypted using the corresponding public key. Some systems share the public key via a digital certificate to provide an additional layer of security around such keys. Specifically, the digital certificate serves as a verification of the validity of the public key. In most instances, a certificate authority acts as a trusted third party by independently verifying the authenticity of the digital certificate (and the public key contained therein) and applying a trusted electronic signature to the digital certificate. When a device receives a digital certificate signed by the trusted certificate authority, the device is assured that the public key in the digital certificate is trustworthy. In other words, the signed digital certificate assures a recipient that the sender of the digital certificate is the true owner of the corresponding public key.
    SUMMARY According to one aspect of the invention, there is provided a method for use in a device arranged to communicate using digital certificates, the method comprising, in response to a request, receiving a digital certificate for use in secure communication between the device and another device, using a logic circuit, evaluating the digital certificate to determine a validity of the digital certificate, if the digital certificate is valid, allowing the device to use the digital certificate , and if the digital certificate is invalid, prohibiting the device from using the digital certificate to allow the device to continue operations despite receiving the invalid digital certificate.
    Optionally or additionally, the method may further comprise notifying a host of the invalidity if the digital certificate is invalid, wherein the host may be configured to track digital certificate expiration dates.
    Optionally or additionally, the digital certificate may include a public key of an asymmetric encryption scheme.
    Optionally or additionally, determining the validity of the digital certificate may include determining whether the digital certificate is based on an unwanted encryption function.
    Optionally or additionally, the unwanted encryption function may be some type of hash function.
    Optionally or additionally, determining the validity of the digital certificate may include determining a size of a key associated with the digital certificate.
    Optionally or additionally, determining the validity of the digital certificate may include determining whether a validity period of the digital certificate corresponds to a time of the device.
    Optionally or additionally, determining the validity of the digital certificate may include determining whether the digital certificate matches a private key of an asymmetric encryption scheme.
    Optionally or additionally, prohibiting the device from using the digital certificate may include rejecting the digital certificate and prohibiting the storage of the digital certificate in the device.
    According to one aspect of the invention, there is provided an apparatus comprising a request generator for generating and transmitting a certificate signing request (CSR), and a certificate verifier for evaluating a digital certificate received in response to the CSR, wherein the certificate verifier is configured to determine if the certificate is valid 1s, if the digital certificate is valid, allow the use of the digital certificate, and if the digital certificate is invalid, prohibit the device from using the digital certificate for protecting the device from adverse effects on the functionality of the device caused by the invalid digital certificate, wherein at least one of the request generator and the certificate verifier is implemented in a logical circuit.
    Optionally or additionally, the certificate verifier may be configured to notify a host of the invalidity when the digital certificate is invalid, wherein the host may be configured to track digital certificate expiration dates.
    Optionally or additionally, the digital certificate may comprise a public key according to an asymmetric encryption scheme.
    Optionally or additionally, the certificate verifier may be configured to determine the validity of the digital certificate by determining whether the digital certificate is based on an unwanted encryption function.
    Optionally or additionally, the unwanted encryption function may be some type of hash function.
    Optionally or additionally, the certificate verifier may be arranged to determine the validity of the digital certificate by determining a size of a key associated with the digital certificate.
    Optionally or additionally, the certificate verifier may be configured to determine the validity of the digital certificate by determining whether a validity period of the digital certificate corresponds to a time of the device.
    Optionally or additionally, the certificate verifier may be configured to determine the validity of the digital certificate by determining whether the digital certificate matches a private key of an asymmetric encryption scheme.
    Optionally or additionally, prohibiting the device from using the digital certificate may include rejecting the digital certificate and prohibiting the storage of the digital certificate in the device.
    According to one aspect of the invention, there is provided a machine-readable storage device comprising instructions which, when executed, cause a machine to receive at least, in response to a request, a digital certificate for use in secure communication between the device and another device, using a logic circuit, evaluates the digital certificate to determine a validity of the digital certificate, when the digital certificate is valid, allows the use of the digital certificate by the device, and when the digital certificate certificate is invalid, prohibits use of the digital certificate by the device.
    BRIEF DESCRIPTION OF THE FIGURES FIG. 1 is a diagram of a system including instances of a connection manager and a device profile manager constructed in accordance with the description of this disclosure.
    fig. 2 is a block diagram showing an exemplary implementation of the connection manager of FIG. 1 displays.
    fig. 3 is a block diagram showing an exemplary implementation of the device profile manager of FIG. 1 displays.
    fig. 4 is a flowchart showing exemplary operations that may be performed to implement the example connection manager of Figures 1 and/or 2 and the example device profile manager of Figures 1 and 3.
    fig. 5 is a block diagram showing an example of a logic circuit capable of executing instructions for implementing, for example, the connection manager of Figures 1 and 2 and/or the example device profile manager of Figures 1 and 3.
    DETAILED DESCRIPTION The teachings of this disclosure have been described with respect to media processing devices, such as printers, and mobile computing devices. However, the teachings of this disclosure can be applied to any suitable type of device using digital certificates. For example, while the teachings of this disclosure are described below with respect to printers, mobile computing devices, and associated data, the teachings of the disclosure may be implemented in personal computers, routers, enterprise equipment, portable computing devices, etc.
    Media processing devices are instructed to, for example, generate indicia on and/or encode media in accordance with received printing and/or encoding instructions. The instructions may be received from an external source, such as a computer in communication with the media processing device over a network (e.g., the Internet or an intranet). That is, the media processing device is accessible to a remote or remote machine.
    The media processing device may implement one or more measures for securing electronic communications with the external machine(s). For example, a media processing device may use an encryption/decryption scheme that uses digital certificates to verify an identity of a public key owner (e.g., in an asymmetric encryption scheme). If the digital certificate is signed by a trusted third party certificate authority instructed to verify ownership of a public key, then a recipient of the digital certificate (and its associated public key) can rest assured that the public key was indeed sent by the listed owner of the public key.
    To increase their effectiveness as security measures, digital certificates have expiration dates. The lifespan of a digital certificate is customizable. Some digital certificates are valid for years, while others are only valid for a few days depending on a desired or required level of security. As such, digital certificates require periodic renewal. A new digital certificate intended to replace a soon-to-be-expiring certificate may contain one or more errors that cause communication based on the digital certificate to become unworkable. Additionally or alternatively, an incorrect digital certificate may have been sent to a device, also rendering communication based on the digital certificate unworkable.
    If a device were to install (i.e. place) an unworkable digital certificate, then one or more services of that device that depend on the digital certificate will stop functioning. That is, when a device receives a defective digital certificate and tries to use it, at least one function of the device will shut down. In some instances, this shutdown translates to complete downtime. For example, if the unworkable function is an interface for receiving printing instructions, then the printer becomes completely unsuitable for receiving instructions and, thus, for performing its core function. For many devices, such as printers with a limited user interface, returning to functionality after a shutdown due to a problematic digital certificate is a time-consuming operation, sometimes requiring manual interaction with the device and/or a service technician visit.
    Known devices are vulnerable to unworkability due to erroneous or defective digital certificates. That is, communication interfaces of known devices are adversely affected by the installation (i.e., placement) of digital certificates that cause the communication interfaces to become unworkable. For many devices, such as printers, the communication interface serves a core function, the performance of which affects the main purpose of the machine, namely, receiving data and printing and/or encoding media based on the received data. Accordingly, devices would benefit from improving the functionality of communication interfaces by ensuring that the communication interfaces do not become inoperable due to defective digital certificates.
    To prevent downtime associated with erroneous or defective digital certificates as experienced by known systems, exemplary methods and devices disclosed herein verify the integrity of received digital certificates prior to installing (i.e., placing or storing) them on the receiving device. That is, exemplary methods and devices disclosed herein determine whether a received digital certificate is problematic in some way (eg, according to customizable criteria) before storing the digital certificate locally. In response to identifying a problem or error with the digital certificate, the exemplary methods and devices disclosed herein explicitly prohibit use of the digital certificate by, for example, rejecting the digital certificate and restricting use of that digital certificate on that device . Additionally, the exemplary methods and devices disclosed herein report findings indicating a problem with the digital certificate such that a new digital certificate can be obtained prior to the expiration of the version of the digital certificate currently used by the device. Thanks to the use of exemplary methods and devices disclosed herein, the device will not attempt to use a defective or erroneous digital certificate, which would otherwise result in device downtime by rendering a communication interface inoperable. Instead, the exemplary methods and devices disclosed herein prevent the defective and/or erroneous digital certificate from causing device downtime.
    fig. 1 shows a system 100 comprising a plurality of devices 102, 104, 106 in communication (e.g., wired, wireless, direct, over a network) with a host 108 dedicated to managing one or more aspects or functions of the plurality of devices 102-106. Each of the devices 102-106 includes a communication interface for transmitting and receiving data, including to and from the host
    108. The host 108 is any suitable type of computing device, such as a server.
    The example host of FIG. 1 includes a device profile manager 110 configured to, among other tasks, interact with a connection manager 112 implemented on each of the plurality of devices 102-106. In general, the device profile manager 110 maintains a report of digital certificates stored on the plurality of devices 102-106 and works with the respective instances of the connection manager 112 on the devices 102-106 to renew the digital certificates used by the devices 102 -106. Each of the devices 102-106 can have any number of digital certificates. For example, one of the devices 102, which is a printer in the example of FIG. 1, has multiple digital certificates, each assigned to a different service or operation. Another of the devices 106, which is a mobile computing device in the example of FIG. 1, has one digital certificate assigned to one service or operation.
    As described above, the digital certificates include encryption information and are used to verify an identity of the owner of the encryption information. In the example of FIG. 1, the encryption information in the digital certificate is a public key of a public/private key pair encryption/decryption scheme. However, the examples disclosed herein are applicable to any type of digital certificate. The exemplary device profile manager 110 of FIG. 1 receives certificate signing requests (CSRs) from the connection managers 112 and sends the CSRs to a certificate authority
    114. A CSR is a request for a digital certificate and, in the example of FIG. 1, is sent from the devices 102-106 to the host 108, which sends the CSR to the certificate authority 114. The sender of the CSR asks the certificate authority 114 to provide a signed (i.e., an electronic approval stamp) digital certificate including the public key contained in the CSR. The certificate authority 114 evaluates the contents of the CSR to determine whether the requester is the true owner of the underlying encryption data (e.g., public key) and signs the corresponding digital certificate if that verification has been made. Accordingly, a digital certificate signed by the certificate authority indicates to recipients of the signed digital certificate that the sender of the digital certificate is the true owner of the encryption information (e.g., public key) contained in the digital certificate. Thus, a holder of the digital certificate can provide the same to external machines such that the external machines trust the holder. In particular, without a valid digital certificate for a specific function of, e.g., the printer 102, the printer 102 cannot perform that function (e.g., receiving printing instructions from an external machine). fig. 2 shows an example implementation of the connection manager 112 of FIG. 1. By way of illustration, the exemplary connection manager 112 of FIG. 2, the instance is deployed in the printer 102 of FIG. 1. The exemplary connection manager 112 of FIG. 2 includes a connection initializer 200, a timing synchronizer 202, digital certificate store 204 (e.g., memory allocated to store digital certificates), a CSR generator 206, a certificate verifier 208, a certificate placer 210, and a stored private key 212. Described in detail below, the connection manager 112 obtains and stores the digital certificates 204 to allow the printer 102 to securely perform respective functions, such as communicating with one or more external devices. Specifically, when receiving a digital certificate, the certificate verifier 208 checks the validity of the digital certificate before storing or otherwise implementing the digital certificate on the printer 102. For example, the certificate verifier 208 determines whether a received digital certificate is problematic for preserving the digital certificate, and if a problem with the digital certificate is identified, the certificate verifier 208 rejects the received digital certificate and the certificate verifier 208 informs the host 108 that another digital certificate is needed. Thus, the sample certificate verifier 208 prevents one or more functions and/or hardware elements of the printer 102 from becoming inoperable as a result of using an erroneous or defective digital certificate. Instead, the certificate verifier 208 improves performance (e.g., output, efficiency, speed, etc.) of the hardware (e.g., printing mechanisms, communication interface, processor, etc.) by preventing damage caused by the installation or other use of invalid digital certificates.
    Other components of the exemplary connection manager 112 of FIG. 2 are described below in connection with FIG. 4.
    fig. 3 shows an example implementation of the device profile manager 110 of FIG. 1. The exemplary device profile manager 110 of FIG. 3 includes a connection initializer 300, a timing synchronizer 302, a certificate acquirer 304, a report generator 306, a CSR requester 308, a certificate authority interface 310, a signed certificate sender 312, and CSR storage 314 (e.g., memory allocated for storing CSRs). As described in detail below in connection with FIG. 4, the device profile manager cooperates with instances of the connection manager 112 on the devices 102-106 to keep the digital certificates used by the devices 102-106 current and valid.
    In addition, the device profile manager 110 provides the devices 102-106 with an intermediary with the certificate authority 114 such that the devices 102-106 can allocate resources (e.g., compute cycles and bandwidth) to core functions (e.g., print, encode, compute, and communicating instructions) instead of communicating with the certificate authority 114. FIG. 4 is a flowchart showing exemplary methods performed by the exemplary connection manager of Figures 1 and/or 2 and the exemplary device profile manager 110 of Figures 1 and/or 3. While the example of FIG. 4 has been described in connection with FIGS. 2 and 3, the methods for the exemplary methods of FIG. 4 can be implemented with additional or alternative implementations of the examples disclosed herein.
    Furthermore, despite the example of FIG. 4 is described in relation to the printer 102 of FIG. 1, the examples Fig. 4 may be implemented in connection with any one of the devices 102-106 of Figs. 1 and/or any other suitable device.
    In the example of FIG. 4, the printer 102 is placed in communication with the host 108 by the connection initializer 200 of the connection manager 112, which cooperates with the connection initializer 300 of the device profile manager 110. In the illustrated example, at block 402, the connection initializer 200 and the connection manager 112 establish a connection 400 (e.g., a communication channel) between the printer 102 and the host 108. In some examples, an external source instructs the printer 102 and/or the host 108 to find each other because, for example, the printer 102 is configured with an address of the host 108 (e.g., a web link to the host 108), or by the host 108 being able to search for devices on a network and provide instructions to found devices (such as the printer 102) to connect to the host
    108.
    In some instances, an internal clock of the printer 102 is not synchronized with a clock of the host 108. Being time synchronized is important when analyzing aspects of digital certificates (e.g., expiration dates). Thus, the time synchronizer 202 of the printer 102 cooperates with the time synchronizer 302 of the host 108 to synchronize the clock of the printer 102 with the clock of the host 108 (block 404). In the example of FIG. 4, the time synchronizer 302 of the host 108 sends a set-get-do (SGD) command to the printer 102 to cause the printer to set the clock of the printer 102 to the current time of the host 108 in Linux Epoch format (e.g. . number of seconds since January 1, 1970). Thus, the exemplary time synchronizer 302 and the SGD command used thereby synchronize the printer 102 independently of any difference in time zones with the host 108 and/or others of the devices 102-106. With the clocks synchronized, expiration dates of digital certificates can be correctly analyzed.
    In the example of FIG. 4, the certificate acquirer 304 sends a request 406 for information associated with the digital certificate stored on the printer 102. In the example of FIG. 4, the certificate acquirer 304 uses an SGD command to request 406 to obtain, for example, the service name and expiration date of each of the digital certificates. The SGD command used by the certificate acquirer 304 as the request 406 allows for automation of the certificate renewal process. For example, a periodic request may be scheduled that automatically retrieves the certificate information, thereby ensuring that the host 108 is aware of the current digital certificates on the printer 102. In response to the request 406, the connection manager 112 gains access to the digital certificates of the digital certificate store 204 and sends the requested digital certificate information 408 to the certificate acquirer 304.
    In the example of FIG. 4, the certificate acquirer 304 provides the received information 408 to the report generator 306. In the illustrated example, the report generator 306 generates and populates a data structure (e.g., a table or a report) with the information 408 associated with the digital certificates (block 410 ). In the example of FIG. 4, the received information 408 is JSON data and the report generator 306 parses the JSON data to identify, for example, a status of the digital certificate (e.g., already expired, active) and relevant information associated with the digital certificates (e.g. ., expiration dates of the digital certificates, a number of days until expiration for each of the digital certificates). Using the report, the device profile manager 110 of the host 108 determines when a digital certificate is approaching expiration and automatically initiates its renewal. The exemplary device profile manager 110 is customizable in terms of, for example, an amount of time to expiration at which renewal is activated.
    The CSR requester 308 of the host 108 sends an instruction 412 (e.g., when the device profile manager 110 determines that a digital certificate renewal is required or is scheduled) to the printer 102 to generate a CSR. In the example of FIG. 4, the CSR generator 206 receives from the printer 102 the instruction 412 and generates a CSR in accordance with the instruction 410 (block 414). The example instruction 410 of FIG. 4 includes fields and field values defining characteristics of the CSR to be generated. Example fields and values in the instruction 410 include a common name for the certificate, which algorithms are supported (e.g., Rivest, Shamir, and Adelman (RSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)), a key size, a curve (when ECDSA is supported), country, locality, organization, state, organizational unit, and contact information. The exemplary CSR generator 206 of FIG. 4 is configured to prohibit the use of outdated security schemes (e.g., outdated hash functions) and to prohibit the use of dimensions that do not conform to industry-accepted recommendations (e.g., proposed by the National Institute of Standards and Technology). In the example of FIG. 4, the CSR generator 206 evaluates the amount of entropy associated with the CSR generation and waits for sufficient entropy before generating the keys and the CSR. If the evaluated conditions and information are acceptable, the example CSR generator 206 generates the CSR and a corresponding private/public key pair. In some examples, the CSR generator logs these events. When the CSR generator 206 has generated the CSR, the CSR generator 206 generates a CSR ready message 416 and sends it to the host 108.
    If the CSR requester 308 of the host 108 determines that the printer 102 has a CSR ready to be signed by a certificate authority 114, the CSR requester 308 sends a request 418 for a CSR to the printer 102. example of fig. 4, the request for CSR 418 is an SGD get command. The printer 102 replies with the
    CSR 420. The sample CSR requester 308 receives the CSR 420 and stores it in the CSR store 316 (block 422.). In the example of FIG. 4, the certificate authority interface 310 of the host 108 sends the CSR (e.g.
    according to SCEP/MSFT protocol) to the certificate authority (CA) 114 to obtain a corresponding signed digital certificate (block 424). If the certificate authority 114 verifies that the requestor associated with the CSR is the true owner of the accompanying encryption information (e.g., public key), the certificate authority 114 sends a signed digital certificate 426 to the host 108 and the host 108 transfers the signed digital certificate 426 to the printer 102.
    The certificate verifier 208 evaluates the validity of the received digital certificate 426 (block 428). In the illustrated example, the certificate verifier 208 performs the evaluation by determining whether forbidden or unwanted features are present in the digital certificate 426. For example, the certificate verifier 208 determines whether a forbidden (e.g., according to custom settings and/or requirements of a security protocol) hash function was used to create the digital certificate. Additionally or alternatively, the certificate verifier 208 determines whether one or more sizes of elements of the digital certificate 426 are outside a designated or desired range. If any of the evaluated characteristics indicate an invalid digital certificate, the sample certificate verifier 208 rejects the digital certificate 426 as invalid and prevents its use on the printer 102 (block 430), which would otherwise render one or more functions of the printer 102 inoperable. Additionally or alternatively, the certificate verifier 208 determines whether the validity period of the digital certificate 426 matches the printer time (i.e., local clock value).
    If not, the sample certificate verifier 208 discards the digital certificate 426 as invalid and prevents its use on the printer 102 (block 430), which would otherwise render one or more functions of the printer 102 inoperable. Additionally or alternatively, the certificate verifier 208 determines whether the digital certificate 426 matches the private key 212 currently in use on the printer 102 and/or the private key associated with the CSR 420. If not, the sample certificate verifier 208 rejects the digital certificate 426 as invalid and prevents its use on the printer 102 (block 430), which would otherwise render one or more functions of the printer 102 inoperable.
    If the certificate verifier 208 determines that the digital certificate 426 is valid, then the sample certificate placer 210 installs the digital certificate 426 on the printer 102 and/or stores the digital certificate 426 in the digital certificate store 204 (block 432). In some examples, only digital certificates residing in storage 204 are available for use on printer 102 and certificate placer 210 acts as a gatekeeper for storage 204 by allowing only digital certificates verified by certificate verifier 208 to be retained. in the digital certificate store 204.
    fig. 5 is a block diagram illustrating a logic circuit that may be used to implement, for example, the example connection manager 112 of Figures 1 and/or 2 and/or the example device profile manager 110 of Figures 1 and/or 3 and/or, more generally, one or more of the devices 102-106 and/or the host 108. The exemplary logic circuit of FIG. 5, a processing platform 500 is suitable for executing instructions for, for example, implementing the exemplary operations depicted by the flowcharts of the drawings accompanying this description. As described below, alternative examples of logic circuits include hardware (e.g., a gate array) configured specifically to perform operations represented by the flowcharts and drawing accompanying this description.
    The exemplary processing platform 500 of FIG. 5 includes a processor 502 such as, for example, one or more microprocessors, controllers, and/or any suitable type of processor. The exemplary processing platform 500 of FIG. 5 includes memory (e.g., volatile memory, non-volatile memory) 504 accessible to the processor 502 (e.g., through a memory controller). The example processor 502 interacts with the memory 504 to obtain, for example, machine-readable instructions stored in the memory 504 that correspond to, for example, the operations represented by the flowcharts of this disclosure. Additionally or alternatively, machine-readable instructions corresponding to the sample operations of the flowcharts can be stored on one or more removable media (e.g., a CD, a DVD, a removable flash memory, etc.) that can be interfaced with the processing platform 500 for granting access to the machine-readable instructions stored thereon.
    The exemplary processing platform 500 of FIG. 5 includes a network interface 506 for allowing communication with other machines via, for example, one or more networks. The exemplary network interface 506 includes any suitable type of communication interface(s) (e.g., wired and/or wireless interfaces) configured to operate in accordance with any suitable protocol(s).
    The sample processing platform 500 of FIG. 5 includes input/output (I/O) interfaces 508 for allowing receiving user input and communicating output data to the user.
    In the foregoing description, specific embodiments have been described. However, those skilled in the art will recognize that various modifications and changes may be made without departing from the scope of the invention as set forth in the claims below. Therefore, the description and figures are to be understood as illustrative rather than limiting, and all such modifications are intended to be included within the scope of the invention of the present specification. In addition, the described embodiments/examples/implements should not be construed as mutually exclusive, and should instead be understood as potentially combinable if such combinations are permissible in any way. In other words, any feature disclosed in any of the above embodiments/examples/implements may be incorporated into any of the other above-mentioned embodiments/examples/implements. In addition, the steps of any method disclosed herein should not be construed as having any particular order unless it is expressly stated that no other order is possible or required by the remaining steps of the particular method. Also, at least some of the figures may or may not be drawn to scale.
    The benefits, solutions to problems, and any element(s) that may cause any benefit or solution to occur or become apparent should not be construed as critical, mandatory, or essential features or elements of any or all of the claims. The invention is defined solely by the appended claims, including any changes made during the course of this application and any equivalents of those claims as published. For clarity and concise description, features are described herein as part of the same or separate embodiments, but it will be understood that the scope of the invention may include embodiments having combinations of all or some of the features described. It will be appreciated that the embodiments shown have the same or similar components, except where they are described as being different.
    In addition, relational terms such as first and second, top and bottom, and the like may be used throughout this document only to distinguish one entity or action from another entity or action without necessarily requiring or implying an actual relationship or sequence between such entities or actions. imply. The terms “comprise”, “comprising”, “has”, “having”, “contains”, “containing” or any variation thereof are intended to cover a non-exclusive inclusion such that any process, process, article, or assembly that a list includes, has, contains not only contains those elements, but may also contain other elements not explicitly mentioned or inherent in such process, method, article, or assembly. An element preceded by “includes. a”, “has…a”, “contains…a” does not exclude, without limitation, the existence of additional identical elements in the process, process, article or arrangement ut comprising, has or contains the element. The term “one” is defined as one or more unless expressly stated otherwise. The terms "substantially", "essential", "near", "approximately" or any other version thereof are defined as close to what is understood by those skilled in the art, and in a non-limiting embodiment the term is defined as being within 10% , in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term "linked" is defined herein as connected, but not necessarily directly and not necessarily mechanically. A device or structure that is "configured" in a certain way is configured in at least that way, but may also be configured in ways not described.
    The above description refers to block diagrams of the accompanying drawings. Alternative implementations of the examples depicted by the block diagrams include one or more additional or alternative elements, processes and/or devices. Additionally or alternatively, one or more of the example blocks of the diagrams can be combined, divided, rearranged or omitted. Components represented by the blocks of the diagrams are implemented by hardware, software, firmware and/or a combination of hardware, software and/or firmware. In some examples, at least one of the components represented by the blocks is implemented by a logic circuit. As used herein, the term "logic circuit" is purposely defined as a physical device comprising at least one hardware component configured (e.g., via operation according to a predetermined configuration and/or via execution of stored machine-readable instructions) to control of one or more machines and/or for performing operations of one or more machines. Examples of a logic circuit include one or more processors, one or more coprocessors, one or more microprocessors, one or more controllers, one or more digital signal processors (DSPs), one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more microcontrollers (MCUs), one or more hardware accelerators, one or more special purpose computer chips, and one or more system-on-a-chip (SOC) devices. Some examples of logic circuits, such as ASICs or FPGAs, are hardware specifically configured to perform operations (e.g., one or more of the operations represented by the flowcharts of this disclosure). Some examples of logic circuits are hardware that executes machine-readable instructions for performing operations (e.g., one or more of the operations represented by the flowcharts of this disclosure). Some examples of logic circuits include a combination of specifically configured hardware and hardware that executes machine-readable instructions.
    The above description refers to flowcharts of the accompanying drawing. The flowcharts are representative of exemplary methods disclosed herein. In some examples, the methods represented by the flowcharts implement the device represented by the block diagrams. Alternative implementations of the exemplary methods disclosed herein may include additional or alternative operations. Furthermore, operations of alternative implementations of the methods disclosed herein may be combined, divided, rearranged, or omitted. In some examples, the operations represented by the flowcharts are implemented by machine-readable instructions (e.g., software and/or firmware) stored on a medium (e.g., a tangible machine-readable medium) for execution by one or more logic circuits (e.g. ., processor(s)). In some examples, the operations represented by the flowcharts are implemented by one or more configurations of one or more specifically designed logic circuits (e.g., ASIC(s)). In some examples, the operations of the flowcharts are implemented by a combination of specifically designed logic circuit(s) and machine-readable instructions stored on a medium (eg.
    a tangible machine-readable medium) to be executed by logic circuit(s).
    As used herein, each of the terms "tangible machine-readable medium", "immutable machine-readable medium" and "machine-readable storage device" is purposely defined as a storage medium (e.g., a hard disk drive, a DVD, a CD, flash memory, read-only memory, random access memory (RAM), etc.) on which to store machine-readable instructions (e.g., program code in the form of, for example, software and/or firmware).
    Further, as used herein, each of the terms "tangible machine-readable medium", "immutable machine-readable medium" and "machine-readable storage device" is purposely defined to exclude moving signals. That is, as used in any claim of this patent, none of the terms "tangible machine-readable medium", "immutable machine-readable medium" and "machine-readable storage device" can be read as implementable by a traveling signal. .
    As used herein, each of the terms "tangible machine-readable medium", "immutable machine-readable medium" and "machine-readable storage device" is purposely defined as a storage medium on which machine-readable instructions are stored for any suitable period of time (e.g., permanent, for an extended span of time (e.g., while a program associated with the machine-readable instructions is executing), and/or a short span of time (e.g., when the machine-readable instructions are cached and/or during a buffering process)).
    While certain exemplary devices, methods and articles of manufacture are disclosed herein, the scope of this patent is not limited thereto. On the contrary, this patent encompasses all devices, methods and articles of manufacture that reasonably fall within the scope of the claims of this patent.
    The summary of the disclosure is provided to give the reader a quick impression of the nature of the technical description. It is filed with the understanding that it shall not be used to interpret or limit the scope or meaning of the claims. In addition, from the foregoing "detailed description" it can be seen that various features are grouped together in different embodiments to streamline the description.
    This manner of description should not be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly stated in each claim. Rather, as the following claims reflect, there is inventive matter in less than all the features of a single described embodiment. Thus, the following claims are incorporated into the "detailed description", each claim standing alone as subject matter separately claimed. The mere fact that certain measures are defined in mutually different claims does not indicate that a combination of these measures cannot be used to an advantage. A multitude of variants will be apparent to those skilled in the art. All variants are understood to fall within the scope of the invention which is defined in the following claims.
    权利要求:
    Claims (19)
    [1]
    A method for use in a device arranged to communicate using digital certificates, the method comprising: in response to a request, receiving a digital certificate for use in secure communication between the device and another device; using a logic circuit, evaluating the digital certificate to determine a validity of the digital certificate; if the digital certificate is valid, allowing the device to use the digital certificate; and if the digital certificate is invalid, prohibiting the device from using the digital certificate to allow the device to continue operations despite receiving the invalid digital certificate.
    [2]
    The method of claim 1, further comprising notifying a host of the invalidity when the digital certificate is invalid, wherein the host is configured to track digital certificate expiration dates.
    [3]
    The method of any preceding claim, wherein the digital certificate comprises a public key of an asymmetric encryption scheme.
    [4]
    The method of any preceding claim, wherein determining the validity of the digital certificate comprises determining whether the digital certificate is based on an unwanted encryption function.
    [5]
    The method of claim 4, wherein the unwanted encryption function is a type hash function.
    [6]
    The method of any preceding claim, wherein determining the validity of the digital certificate comprises determining a size of a key associated with the digital certificate.
    [7]
    The method of any preceding claim, wherein determining the validity of the digital certificate comprises determining whether a validity period of the digital certificate corresponds to a time of the device.
    [8]
    The method of any preceding claim, wherein determining the validity of the digital certificate comprises determining whether the digital certificate matches a private key of an asymmetric encryption scheme.
    [9]
    The method of any preceding claim, wherein prohibiting the device from using the digital certificate comprises rejecting the digital certificate and prohibiting the storage of the digital certificate in the device.
    [10]
    An apparatus comprising: a request generator for generating and transmitting a certificate signing request (CSR); and a certificate verifier for evaluating a digital certificate received in response to the CSR, the certificate verifier configured to: determine whether the certificate is valid; if the digital certificate is valid, allowing the use of the digital certificate; and if the digital certificate is invalid, prohibiting the device from using the digital certificate to protect the device from adverse effects on the functionality of the device caused by the invalid digital certificate, whereby at least one of the request generator and the certificate verifier is implemented in a logical circuit.
    [11]
    The apparatus of claim 10, wherein the certificate verifier is configured to notify a host of the invalidity when the digital certificate is invalid, wherein the host is configured to track digital certificate expiration dates.
    [12]
    The apparatus of any one of claims 10 to 11, wherein the digital certificate comprises a public key according to an asymmetric encryption scheme.
    [13]
    The apparatus of any one of claims 10 to 12, wherein the certificate verifier is configured to determine the validity of the digital certificate by determining whether the digital certificate is based on an unwanted encryption function.
    [14]
    The device of claim 13, wherein the unwanted encryption function is a type of hash function.
    [15]
    The apparatus of any one of claims 10 to 14, wherein the certificate verifier is configured to determine the validity of the digital certificate by determining a size of a key associated with the digital certificate.
    [16]
    The apparatus of any one of claims 10 to 15, wherein the certificate verifier is configured to determine the validity of the digital certificate by determining whether a validity period of the digital certificate corresponds to a time of the device.
    [17]
    The apparatus of any one of claims 10 to 16, wherein the certificate verifier is configured to determine the validity of the digital certificate by determining whether the digital certificate matches a private key of an asymmetric encryption scheme.
    [18]
    The apparatus of any one of claims 10 to 17, wherein prohibiting the device from using the digital certificate includes rejecting the digital certificate and prohibiting the storage of the digital certificate in the device.
    [19]
    A machine-readable storage device comprising instructions that, when executed, cause a machine to at least: in response to a request, receive a digital certificate for use in secure communication between the device and another device; using a logic circuit, evaluates the digital certificate to determine a validity of the digital certificate; if the digital certificate is valid, allows use of the digital certificate by the device; and if the digital certificate is invalid, prohibits use of the digital certificate by the device.
    类似技术:
    公开号 | 公开日 | 专利标题
    KR20200099543A|2020-08-24|A system and method for recording device lifecycle transactions as version blocks in a blockchain network using transaction connector and broker services
    US20200019714A1|2020-01-16|Distributed data storage by means of authorisation token
    JP6526244B2|2019-06-05|Secure Delegated Delivery of Private Keys via Domain Name Service
    CN109328352B|2021-06-15|Targeted secure software deployment
    JP6357158B2|2018-07-11|Secure data processing with virtual machines
    US20110276490A1|2011-11-10|Security service level agreements with publicly verifiable proofs of compliance
    US8572368B1|2013-10-29|Systems and methods for generating code-specific code-signing certificates containing extended metadata
    JP2017157018A|2017-09-07|Information processing device, information processing method, information processing program, and trusted platform module
    US11070542B2|2021-07-20|Systems and methods for certificate chain validation of secure elements
    US8391487B2|2013-03-05|Secure remote configuration of device capabilities
    US11223482B2|2022-01-11|Secure data exchange
    US10439804B2|2019-10-08|Data encrypting system with encryption service module and supporting infrastructure for transparently providing encryption services to encryption service consumer processes across encryption service state changes
    CN101369296A|2009-02-18|Method and system for implementing off-line printing limitation
    BE1027391B1|2021-11-08|METHODS AND DEVICE FOR RENEWING DIGITAL CERTIFICATES
    US9305182B1|2016-04-05|Managing distribution of sensitive information
    KR20180024389A|2018-03-08|Apparatus and method for key management
    US10686612B2|2020-06-16|Cryptographic data
    WO2020233086A1|2020-11-26|Block processing method and apparatus, computer device and storage medium
    CN112307457A|2021-02-02|Method and integrated circuit for updating a certificate revocation list in a device
    US10715338B2|2020-07-14|Management of public key certificates within a distributed architecture
    WO2020049452A1|2020-03-12|Methods and devices for managing user identity authentication data
    US10574459B2|2020-02-25|Code signing service
    US9948632B2|2018-04-17|Sharing data between sandboxed applications with certificates
    US20110158401A1|2011-06-30|System and method for signing electronic document
    WO2021014511A1|2021-01-28|Test system, test method, and test program
    同族专利:
    公开号 | 公开日
    GB202114335D0|2021-11-24|
    GB2598846A|2022-03-16|
    WO2020263381A1|2020-12-30|
    CN114073038A|2022-02-18|
    US20200412552A1|2020-12-31|
    BE1027391A1|2021-01-28|
    KR20220018586A|2022-02-15|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20130132718A1|2009-04-28|2013-05-23|Sunil C. Agrawal|System And Method For Long-Term Digital Signature Verification Utilizing Light Weight Digital Signatures|
    US20140283054A1|2013-03-14|2014-09-18|Microsoft Corporation|Automatic Fraudulent Digital Certificate Detection|
    US20140337616A1|2013-05-07|2014-11-13|The Boeing Company|Verification of Aircraft Information in Response to Compromised Digital Certificate|
    US20180062859A1|2016-08-26|2018-03-01|Microsoft Technology Licensing, Llc|Evolving a signature during trust verification of an object|
    US6272538B1|1996-07-30|2001-08-07|Micron Technology, Inc.|Method and system for establishing a security perimeter in computer networks|
    US20050078830A1|2003-08-15|2005-04-14|Imcentric, Inc.|Method for automated installation of digital certificates to network servers|
    WO2005062919A2|2003-12-22|2005-07-14|Wachovia Corporation|Public key encryption for groups|
    CN1271485C|2004-01-08|2006-08-23|中国工商银行股份有限公司|Device and method for proceeding encryption and identification of network bank data|
    JP2012520027A|2009-03-06|2012-08-30|インターデイジタルパテントホールディングスインコーポレイテッド|Verification and management of wireless device platforms|
    US10436875B2|2010-07-15|2019-10-08|Zebra Technologies Corporation|Method and apparatus for determining system node positions|
    US9280651B2|2012-09-10|2016-03-08|Microsoft Technology Licensing, Llc|Securely handling server certificate errors in synchronization communication|
    法律状态:
    2022-01-10| FG| Patent granted|Effective date: 20211108 |
    优先权:
    申请号 | 申请日 | 专利标题
    US16/456,663|US20200412552A1|2019-06-28|2019-06-28|Methods and Apparatus to Renew Digital Certificates|
    [返回顶部]